@HannesWell please note: code in src-gen is generated and would need a change to the upstream fragment in xtext

@HannesWell I see what you're doing here but I fail to understand the why beyond fewer deps are better

Can you help me understand the reasoning?

@HannesWell please note: code in src-gen is generated and would need a change to the upstream fragment in xtext

Yes. Can you point me to where this has to be done?

@HannesWell I see what you're doing here but I fail to understand the why beyond fewer deps are better

Can you help me understand the reasoning?

Fewer deps are better :) especially since Guava is often a very difficult dependency (one reason is xtext re-exporting it), see for example:
eclipse-xtext/xtext#2671

And since the Java standard-library provides almost drop-in replacements or at least simple alternatives, I assumed this would be straight forward.

If (and that's a big if) we (as a community) want to put effort into this, it should start with Xtext and a plan to avoid the re-export without breaking clients. That should be discussed in Xtext.

@HannesWell please note: code in src-gen is generated and would need a change to the upstream fragment in xtext

I created eclipse-xtext/xtext#2976 for that, if I'm not mistaken, changes the template so that the LanguageActivator should not use the Guava method anymore after the next rerun of the workflow.

The adjustment to not use Guava in the template for Mwe2Parser is still pending.

If (and that's a big if) we (as a community) want to put effort into this, it should start with Xtext and a plan to avoid the re-export without breaking clients. That should be discussed in Xtext.

At least I would be willing to put some effort into this. :)
But I created eclipse-xtext/xtext#2975 in order to discuss that for Xtext.

In order to be able to replace the remaining usages of Guava I have created the following PRs in Xtext:

• Deprecate and replace Guava-using APIs in ContainersStateFactory and its dependencies eclipse-xtext/xtext#2979
• Deprecate and replace Guava-using APIs in Scopes and QualifiedName eclipse-xtext/xtext#2978

I have already added a second commit that leverages those future changes which is why the build fails. If they are available I'll just squash the commits.

@HannesWell please note: code in src-gen is generated and would need a change to the upstream fragment in xtext

I created eclipse/xtext#2976 for that, if I'm not mistaken, changes the template so that the LanguageActivator should not use the Guava method anymore after the next rerun of the workflow.

Created eclipse-xtext/xtext#2990 which should cover the last part of generated code.